home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / newsgroups / misc.19950726-19950929 / 000334_news@columbia.edu_Mon Sep 11 13:14:29 1995.msg < prev    next >
Internet Message Format  |  1995-12-25  |  2KB
  1. Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA00335
  2.   (5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Mon, 11 Sep 1995 09:14:34 -0400
  3. Received: by apakabar.cc.columbia.edu id AA27345
  4.   (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Mon, 11 Sep 1995 09:14:32 -0400
  5. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  6. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  7. Newsgroups: comp.protocols.kermit.misc
  8. Subject: Re: Speeding up Kermit
  9. Date: 11 Sep 1995 13:14:29 GMT
  10. Organization: Columbia University
  11. Lines: 41
  12. Message-Id: <431cnl$qmf@apakabar.cc.columbia.edu>
  13. Nntp-Posting-Host: watsun.cc.columbia.edu
  14. Apparently-To: kermit.misc@watsun.cc.columbia.edu
  15.  
  16. In article <43004r$hkp@nntp5.u.washington.edu>,
  17. Brian Wirt <wirt@u.washington.edu> wrote:
  18. : My problem is that transfer of compressed files from a host to my home PC 
  19. : runs only around 600cps (i.e. zip files) on a 14.4 modem.  Uncompressed 
  20. : files seem to transfer quite well.  Here are the parameters I'm using:
  21. : 
  22. : set file type binary
  23. : set receive packet 1024
  24. : set window 4
  25. : set send packet-length 1024
  26. : set block 2
  27. : 
  28. That's a good start.  A few things to note:
  29.  
  30.  1. The packet length is governed by the file receiver.  Thus, when
  31.     uploading you have to give the "set receive packet-length" command to
  32.     the *other* Kermit program.  The "set send packet-length" command
  33.     doesn't do anything except override (and only downwards, never
  34.     upwards) the *other* Kermit's packet-length request.
  35.  
  36.  2. "set block 3" is recommended.  It's generally a false economy to use
  37.     less powerful block checks.
  38.  
  39. Now, why is the transfer still so slow?
  40.  
  41.  1. Check your flow control.  Use hardware flow control if possible;
  42.     otherwise you are likely to get buffer overruns, and therefore
  43.     retransmissions.
  44.  
  45.  2. Try a bigger window size.  In general, the bigger the window size,
  46.     the better, provided flow control is effective.
  47.  
  48.  3. Try a bigger packet length if your connection is relatively noise
  49.     free (and well-flow controlled).
  50.  
  51. Finally, assuming you are running MS-DOS Kermit 3.14 or C-Kermit 5A(189)
  52. or later, read in the update notes (KERMIT.UPD or ckcker.upd) about
  53. control-character "unprefixing", which will add another 25% to your
  54. throughput right away when transferring ZIP files.
  55.  
  56. - Frank